home *** CD-ROM | disk | FTP | other *** search
/ MacAddict 4 / MacAddict_004_1996_12.iso / Essentials / MacTCP 2.0.6 / release_notes < prev   
Text File  |  1994-11-26  |  4KB  |  79 lines
  1. Release Notes for MacTCP 2.0.6
  2. Copyright ©1994, Apple Computer, Inc.
  3. All rights reserved.
  4. November 22, 1994
  5.  
  6. MacTCP version 2.0.6 is an update release.  
  7. MacTCP version 2.0.5 was only released internal to Apple.
  8. MacTCP 2.0.6 contains the following improvements over MacTCP 2.0.4
  9. and earlier versions:
  10.  
  11. Domain Name Resolver:
  12. ---------------------
  13.  
  14. •    Inbound Domain Name Server replies are now processed one Resource Record
  15. (RR) at a time in order to avoid exhausting the DNR's limited pool of memory. This
  16. allows 2.0.6 to swallow the most verbose BIND 4.9.2/3 ADDAUTH PTR replies
  17. without encountering an out-of-memory error condition.
  18.  
  19. •    The DNR now only caches A and CNAME RRs from the Answer section. NS RRs
  20. from Authority and A RRs from Additional are used to recursively follow-up
  21. references if that's necessary, but they are not stored. This greatly reduces
  22. the demand placed on the DNR's limited memory pool. It also transforms the
  23. DNR almost totally into a Stub Resolver (see RFCs 1034 and 1035). As a side
  24. effect, each new query starts off with only the name server information
  25. originally configured in the control panel or from a server. This makes the
  26. choice of which server(s) to contact, and the order in which they will be
  27. contacted, much more determinate and under the control of the configuring
  28. administrator.
  29.  
  30. •    Several small memory leaks have been fixed, including a corner case in
  31. MacTCP 2.0.4 in which a block of memory could be freed twice, causing
  32. indeterminate problems later on.  
  33.  
  34. •  The DNR is now fully up to date in terms of permitted and forbidden
  35. syntax for domain names. 
  36.  
  37. •    Domain name syntax checking has been extended to cover MXINFO and
  38. HINFO requests; previously only A requests (String To Address) went
  39. through this check.
  40.  
  41. Performance:
  42. ------------
  43.  
  44. • Previous versions of MacTCP kept track of retransmission timers on a
  45. per segment basis.  If 4 successive segments were dropped due to
  46. congestion at a gateway, the retransmission of each one would require a
  47. separate time-out, and each would force an additional exponential back-off. 
  48. Because of this, retransmission time-outs sometimes became excessively
  49. long.  In MacTCP 2.0.6, retransmission of a group of segments does not
  50. result in further exponential back-offs.
  51.  
  52. • Under certain conditions, MacTCP 2.0.6 will assume that a duplicate ack
  53. implies that retransmission of data will be required, and will expedite the
  54. retransmission process.   This often results in much shorter retransmission
  55. delays when MacTCP is sending data.
  56.   
  57. Configuration:
  58. -------------
  59.  
  60. • Previous versions of MacTCP checked both the source and destination port
  61. field in Bootp configuration responses, and did not accept the response unless
  62. the source port was 67 (Bootp Server) and the destination port was 68 (Bootp
  63. Client). Because the Bootp protocol permits Bootp Relay Agents (which are
  64. Clients) to relay configuration packets from their own Client port address
  65.  MacTCP failed to accept valid Bootp responses passing through Bootp Relay
  66. Agents that implemented this feature.   MacTCP 2.0.6 now only checks the
  67. destination port for validity.
  68.  
  69. • When configuring via Bootp, previous versions of MacTCP saved only the
  70. last Domain Name Server returned in a Bootp reply. In cases where only one
  71. DNS server was returned, this didn't matter. When more than one server was
  72. returned, the one saved (the last one) was usually the least desirable server.
  73. 2.0.6 is still limited by architectural constraints to using a single
  74. Bootp-configured DNS server, but it now saves the first one returned - that
  75. is, the "best" or most desirable server in the list.
  76.  
  77. • Previous versions contained a bug in the Bootp configuration code for the
  78. processing of the Default Gateway option that could have led the DNR to
  79. corrupt any portions of a Bootp reply following that option.